The existing BMI adapter for Fortran modules will not behave correctly in situations when the size of Fortran types is modified from the "standard" expected size. This is because the adapter does not ask the module directly for variable item sizes when deciding what corresponding type to use for values inside the framework.

For example, consider this method from Bmi_Fortran_Adapter:

            inline void inner_get_value(const std::string& name, void *dest) {
                std::string varType = inner_get_var_type(name);
                //Can use the C type or the fortran type, e.g. int or integer
                if (varType == "int" || varType == "integer") {
                    inner_get_value_int(name, (int *)dest);
                }
                else if (varType == "float" || varType == "real") {
                    inner_get_value_float(name, (float *)dest);
                }
                else if (varType == "double" || varType == "double precision") {
                    inner_get_value_double(name, (double *)dest);
                }
                else {
                    throw ::external::ExternalIntegrationException(
                            "Can't get model " + model_name + " variable " + name + " of type '" + varType + ".");
                }
            }

The adapter only asks for a variable's type and assumes the appropriate item size strictly based on the type name string: e.g., that an advertised integer will be the same size as a C++ int. This is not guaranteed to be correct, as type resizing can be done at compile time, using flags like gfortran's -fdefault-real-8.

Changes

• Correct get_analogous_cxx_type to get the C++ type corresponding to not just the category (i.e., integer, float) but also the memory size of a variable
• Correct adapter BMI getter/setter functions similarly, having them now defer to get_analogous_cxx_type for determining how types should be handled
• Moving the first level of getter/setter logic from "inner" methods to directly within the main BMI GetValue/SetValue implementations, since updated implementations now violated the intended premise of "inner" functions for the class.

Testing

1. Existing unit tests pass as they did previously (actually, they are ... there are a few failing (though seemingly unrelated) tests ... I'm investigating)

Notes

• I removed some "inner" functions (see the header file for details), because doing so fell within the scope. The necessary updates violated the stated premise for "inner" functions, thus imposing a need to move where the logic was placed (and thereby making redundant the functions that were removed). The class would likely benefit from refactoring to remove other "inner" functions also, and just have logic be directly within the implemented BMI functions. However, that would be beyond the scope for this.

Todos

• Before taking out of draft status, I need to confirm the functionality by re-compiling the Fortran components locally with the adjusted precision, and then running a few tests.

Checklist

• PR has an informative and human-readable title
• Changes are limited to a single goal (no scope creep)
• Code can be automatically merged (no conflicts)
• Code follows project standards (link if applicable)
• Passes all existing automated tests
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future todos are captured in comments
• Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)
• Reviewers requested with the Reviewers tool ➡️

Testing checklist (automated report can be put here)

Target Environment support

• Linux